1. Field of Invention
The present invention is generally related to business software applications, and in particular to methods for improved net traffic efficiency by clients uniquely identifying servers before getting authenticated.
2. Background
In Oracle database system environments, the database application and the database itself are separated into two parts and interconnected by a network. A client part runs the application that accesses database information and that interacts with a user. A server part runs software providing for concurrent, shared data access to an Oracle database. The client application and Oracle server could be run on the same computer, but typically users run the client and server on different computers connected through a network.
A distributed processing environment has many benefits. Oracle database system servers and clients communicate through Oracle's network interface, e.g., Oracle Net Services. Client applications can be hosted on multiple simple and inexpensive platforms.
Clients request input from users, get data from the servers, and then analyze and present the results on the client workstations. Client applications are typically not concerned with the physical location of the data. Even when critical data is moved or distributed to other database servers, these applications can continue to function with little or no modification.
Oracle uses multitasking and shared-memory facilities in the underlying operating system for concurrency, data integrity, and performance in its client applications.
Client workstations can be optimized for data presentation, and the servers can be optimized for high speed data processing with large amounts of memory and disk space storage.
In networked environments, the client applications submit database requests to the server using structured query language (SQL) statements. These are processed by the server, and any results are returned to the client application. Network traffic was considered to be kept to a minimum, because only the requests and the results are carried over the network. Net traffic can be further optimized by reusing some of the messages that occur in Oracle networks.
Conventionally, each Oracle instance is uniquely identified to a client by a hostname, dbname, and instance name that are sent to the client after authentication. For a Real Application Clusters database, each node within a cluster usually has one instance of the running Oracle software that references the database. When a database is started, Oracle allocates a memory area called the System Global Area (SGA), and starts one or more Oracle processes. Such combination of SGA and Oracle processes is referred to as an instance. Each instance has a unique Oracle system identifier, instance name, rollback segments, and thread identification (ID).
The initsid.ora is an instance initialization parameter file that contains parameters unique for an instance and that points to initdbname.ora for database parameters. The instance name represents the name of the instance and is used in the prior art to uniquely identify a specific instance when clusters share common services names. The instance name is identified by the INSTANCE_NAME parameter in the instance initialization file, initsid.ora. The instance name is the same as the Oracle system identifier.
The Oracle system identifier identifies a specific instance of the running Oracle software. For a Real Application Clusters (RAC) database, each node within the cluster has an instance referencing the database. The database name, specified by the DB_NAME parameter in the INITDB_NAME.ORA file, and unique thread ID make up each node's sid. The thread ID starts at “1” for the first instance in the cluster, and is incremented by one for the next instance.
Oracle already uses a unique database ID for each database store. Any number of instances of the same database (RAC) and shutdown/restarts will use the same ID. If the database is cloned, the ID also gets cloned.
Oracle uses a tuple with a hostname, dbname, instancename and incarnation time to uniquely identify a database instance. Such is sensitive information and each client is not provided this information until after being authenticated with the database. So the database ID will be kept secret and cannot be used prior to authentication.
In general, agents which must register with a common system over a network before work can begin, they typically have to authenticate themselves and then have to exchange capability and resource information. If they have connected before, the exchange of capability and resource information in later sessions becomes redundant. If there are many such agents all competing for network bandwidth, the redundant traffic can become significantly wasteful.
What is needed are improved methods of unique instance identification that can increase the efficiency of authentication while reducing the network traffic for the same.